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(54) Title: VALIDATION GATEWAY 

(57) Abstract 

A method for billing a customer credit card account 
includes the steps of (a) sending a validation request message 
from a caller interaction processor to a validation gateway 
(308); (b) converting the validation request message from a 
client server protocol to a packet switching network protocol 
(310); (c) sending a card request message from the validation 
gateway to a financial processor for authorization to charge 
the customer credit card account (312); (d) sending a card 
reply message from the financial processor to the validation 
gateway (314); (e) converting from the packet switching 
protocol to the client server protocol (316); (f) sending a 
validation response message from the validation gateway to 
the caller interaction processor (318). 
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VALIDATION GATEWAY 



Background of the Invention 
Field of the Invention 

25 

The present invention relates generally to computer systems, and more 
particularly to providing a messaging interface between one or more computer 
system environments. 

30 Related Art 

Telecommunications network products are services provided by telephone 
companies that are carried on telecommunications networks. A widely known 
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example is dial-l long distance voice service which allows a customer to dial a 
1 plus a ten digit number from his or her home telephone, talk to a party who 
answers the telephone on the line of the tea digit number dialed and pay for the 
telephone call when billed at the end of the month. Although dial-l is popular, 
other calling and payment options are sometimes preferable. For example, a 
railing card call allows an individual to make a call from a phone other than their 
home phone and charge the call to the home phone account using the calling card. 

One such calling and payment option is debit calling which is also referred 
to as prepaid calling. Debit «* H«»g allows a customer to put funds in an account 
and have those funds debited each time a telephone call is made. Standard debit 
call processing includes verification of the account balance prior to connecting 
the call and ongoing balance verification during the call. An example of a typical 
debit calling customer is a parent who purchases a debit calling card for a child 
away from home. 

Once a debit account is established, a customer may add funds to the debit 
account. Customers often add funds to their debit accounts using credit cards. 
To add funds, a customer contacts the telephone company by dialing a telephone 
number that is answered by a customer service representative or an operator and 
requests that funds be added to the debit account. The customer service 
representative or operator collects information from the customer and processes 
the request to add funds. In order to add funds, the customer must select a 
method of payment and the customer service representative or operator must 
obtain authorization and enter the information needed to later bill the customer. 

If the customer chooses to pay for funds added to a debit account using a 
credit card, authorization for charges must be obtained from the financial 
institution that provides the credit card account to the customer. Authorization 
to charge to a customer's credit card account is typically obtained by accessing a 
computer system owned by the financial institution. The computer system 
typically includes a database with customer account information and one or more 
computer programs that can determine using the customer's account information 
whether to authorize billing a particular transaction to the customer's credit card 
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account When the financial institution authorizes a transaction, the telephone 
company receives an authorization response code which reflects a commitment 
from the financial institution that it will pay the telephone company for the 
services provided. 

Because the computer systems used by financial institutions communicate 
using a different protocol man the computer systems operating on 
telecornmunications networks, protocol conversion is needed for the computer 
systems operating on telecommunications networks to automatically access the 
computer systems used by financial institutions that authorize billing transactions. 
A protocol is a standard that computer programs follow to be compatible with 
other computer programs. Protocols determine what information is transmitted, 
what riming values should be associated with the transfer of information, and 
what format should be used to transmit the information. A standard or protocol 
may be used throughout the telecommunications industry or it may be owned by 
a private entity for use with computer systems sold or operated by that entity. 
Telecommunications network components are available that allow 
communication between the computer systems operating on the 
telecorrmumcations network and the computer systems used for financial 
institutions for real-time authorization of charges processed by a human operator. 
However, these components do not allow for real-time authorization of charges 
processed automatically and they do not provide real-time updates to telephone 
company computer systems that process billing for other tdecommunications 
products. 

Computer systems used by telephone companies process billing 
differently than the computer systems used by financial institutions. Typically, 
billing for a telecommunications product cannot occur until after a call is 
complete because billing is dependent on the duration of the call. For example, 
when a customer uses a calling card with added features, such as the ability to 
access news and weather, the processing of the billing for the call involves a two 
step process. First, the computer systems of the telecommunications network that 
process calling cards provide a record of the use of the calling card to computer 
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systems that process billing for the telephone company. Second, a switch, which 
is a component within the telecommunications network, provides the call duration 
information to the telephone company billing computer systems. Then, the 
telephone company billing computer systems reconcile these records. 

However, unlike billing for a call using a calling card with added features, 
billing for a request to add funds to a debit account is not dependant on call 
duration. The customer requests to add a specified amount to a debit account 
The duration of the call affects the amount of funds deducted from the account 
at the end of the call but not the amount added to the customer's account 
Therefore, the addition of the specified amount to the debit account can be 
performed as a single transaction. Unfortunately, current telephone company 
billing computer systems are not programmed to process billing a single 
transaction. As a result reconciliation of the records of the telephone company 
billing computer systems and the records of the financial institution's billing 
computer systems is currently not real-time. The process of reconciling the 
records of the telephone company billing computer systems and the financial 
institution's billing computer systems is referred to as settlement 

Summary of the Invention 



The system and method of the present invention provide communication 
between telecommunications networks and computer systems used by financial 
institutions in order to process customers 1 requests to pay for telecommunications 
services with their credit cards. Both real-time authorization and settlement of 
charges are possible with the present invention. In addition, the present invention 
provides protocol conversion between a client server protocol used by 
telecommunication networks and aX.25 protocol used by the computer systems 
of financial institutions. The protocol conversion allows communication for 
requests to bill using a credit card processed both by a human operator and 
automatically. 
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The system of the present invention comprises a validation gateway that 
has a computer program that provides for the transfer of messages and conversion 
of protocol to allow communication between the telecommunications network 
that received the call and the computer system used by the financial institution 
that provides the customer with credit card services. The validation gateway 
operates in an interexchange network to provide an interface between the 
interexchange network and computer systems owned by financial institutions. An 
interexchange network is a telecommunications network that provides long- 
distance telephone service and other telecommunications services. 

The computer program on the validation gateway includes software 
modules that perform specified functions. Modules within the computer program 
of the validation gateway receive messages from and send messages to caller 
interaction processors. Caller interaction processors are processors that allow a 
human operator to interact or interact directly with a debit customer to receive 
call processing information from the customer. Two examples of caller 
interaction processors are manual operator consoles and service switching control 
points (SSCPs). The manual operator console is a computer that is similar to a 
personal computer and is operated by a human operator to provide the human 
operator with information necessary to request information from the customer and 
enter information provided by the customer to process the call. The SSCP 
provides automated call processing for a debit customer who uses a keypad to 
enter information that is received by the SSCP. 

The computer program on the validation gateway also includes software 
modules that send messages to and receive messages from the computer systems 
used by financial institutions, which are referred to as financial processors. 
Financial processors are the computer systems used by financial institutions to 
authorize charges to credit card accounts. These modules act as a single point of 
interface for the transfer of multiple customers' messages between the validation 
gateway and the financial processor. 

In addition, the computer program on the validation gateway includes a 
module that converts between the protocol used by the caller interaction 
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processors and the protocol used by the' financial processors for credit card 
authorization. This module accepts validation request messages in a request 
information format Tte module stores information received in the message and 
builds a card request message to send to the financial processor. This module 
also accepts a card reply message from the financial processor, retrieves the 
stored mformation, and builds a validation response message to send to the caller 

interaction processor. 

The method of the present invention comprises steps for receiving, 
converting protocol, and sending messages to process customer credit card 
requests. The method of the present invention includes steps for receiving a 
validation request message from a caller interaction processor, building a card 
request message that can be understood by the financial processor, and sending 
the card request message to the financial processor. The method of the present 
invention also includes steps for receiving a card reply message from the financial 
processor, building a validation response message that can be understood by the 
caller interaction processor, and seeding the validation response message to the 

caller interaction processor. 

The system and method of the present invention is not limited to 
processing credit card authorization requests. The caller interaction processors 
are cheats operating on a client server network. A client server network is a 
network or one or more computer systems that include multiple clients which are 
controlled and monitored by one or more servers. In this case, the caller 
interaction processors are clients that are controlled and monitored by operator 
network center computer systems, which are servers. In addition, the present 
invention may be used to communicate with any processor that is accessed via a 
packet switching network and is not limited to accessing a financial processor. 
Therefore, the system and method of the present invention may provide protocol 
conversion between any client server protocol used by a client and any packet 
switching protocol used by a processor to allow message transfer. 

The system and method of the present invention also allows access by 
financial process rs to computer systems operated by the telephone company that 
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validate calling cards, prepaid cards, and ther cards provided by that telephone 
company. The present invention accepts requests from the network used by 
financial processors, typically an X.25 network, promts a protocol conversion, 
transmits the request to the appropriate computer system on the 
telecommunications network, and provides a reply to the requestor via the 3C25 
network. The modules of the computer program on the validation gateway 
perform the same functions, although in a different order, to process these 
requests. 

Further features and advantages of the invention, as well as the structure 
and operation of various embodiments of the invention, are described in detail 
below with reference to the accompanying drawings. In the drawings, like 
reference numbers generally indicate identical, functionally similar, and/or 
stroctur?.Uy similar elements. The drawing in which an element first appears is 
indicated by the leftmost digits in the corresponding reference number. 

Brief Description of the Figures 

FIG. 1 is a block diagram of an interface environment of a validation 
gateway according to a preferred embodiment of the present invention; 

FIG. 2 is a block diagram of the structure of a validation gateway of the 
interface environment of FIG. 1 according to a preferred embodiment of the 
present invention; 

FIG. 3 illustrates the message flow between a manual operator console 
and the financial processor according to a preferred embodiment of the present 
invention; 

FIG. 4 illustrates the protocol conversion from a client server protocol to 
X.25 according to a preferred embodiment of the present invention; 

FIG. 5 illustrates the protocol conversion from X.25 to a client server 
protocol according to a preferred embodiment of the present invention; 

FIG. 6 illustrates the message flow between the SSCP and the financial 
processor according to a preferred embodiment of the present invention; 
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FIG. 7 illustrates the message flow for creating a billing data record by a 
validation gateway according to a preferred embodiment of the present invention; 

FIG. 8 aiustrates the message flow for validating a request message 
received on an X25 permanent virtual circuit according to a preferred 
embodiment of the present invention; and 

FIG. 9 illustrates the message flow for validating a request message 
received on an X.25 switched virtual circuit according to a preferred embodiment 
of the present invention. 

Detailed Description of the Preferred Embodiments 

FIG. 1 is a block diagram of a validation gateway interface environment 
1 02 according to a preferred embodiment of the present invention. The validation 
gateway 130 provides access to the financial processor 132 to allow for credit 
card validation. 

The validation gateway interface environment 102 is one possible 
environment of a validation gateway 130. The validation gateway interface 
environment 102 described below includes the telecommunications network 
necessary to process customer requests to add funds to a debit account The 
validation gateway 130 allows the components of the telecommunications 
network to communicate with a financial processor 132. A financial processor 
132 is a computer system that provides authorization of credit card charges. The 
financial processor 132 typically uses X.25 protocol and can be accessed via an 
X.25 network. A typical call may be processed manually by a human operator 
using a manual operator console 122A or automatically via the service switching 
control point (SSCP) 138. 

The telecommunications network components include several 
telecommunications networks such as first and second local exchange networks 
106 and 134 and an interexchange network 1 10. The interexchange network 110 
comprises a plurality of switches including an interexchange network switch 108 
and a bridging switch 1 12. In addition, within the interexchange network 1 1 0, an 

SKGF Ref. No- 1575.2250000 
MCI Ref. No.: CDR-96-011 
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automated call distributor (ACD) 1 14, an intelligent service network applications 
processor (ISNAP) 116, manual operator consoles 122A, 122B, ... I22n, an 
advanced intelligent network gateway (AIN) i24 t a service data point (SDP) 128. 
and the validation gateway 1 30 are used to process debit customer requests to add 
funds to debit accounts that arc handled by a human operator. If the validation 
request to add funds to a debit account is processed automatically, the SSCP 138, 
the SDP 128, the AIN 124, the validation gateway 1 30, and a billing data record 
(BDR) server 140 are used. Please refer to the attached Glossary for a reference 
of acronyms and their definitions. 

The interface environment of a validation gateway 130 can best be 
described referencing the processing of a typical call. The interface environment 
of a validation gaieway 130 will first be described with reference to a typical call 
that is processed manually by a human operator. 

A call is placed by a debit customer using a telephone 104. The call is 
received by a first local exchange network 1 06. A first local exchange network 
106 comprises switches and termination equipment within a localized area. An 
example of a first local exchange network 106 is a local telephone operating 
company network such as Bell Atlantic. The first local exchange network 106 
sends the call to an interexchange switch 1 08A in an interexchange network 110. 

Similar to the first local exchange network 1 06, an interexchange network 
110 comprises a plurality of switches, also referred to as exchanges, that are 
located throughout a geographic area. However, interexchange networks 1 10 
typically comprise of switches throughout a large geographic area to process long- 
distance telephone calls. For example, a national interexchange network 110 
comprises switches located throughout the nation. When a call is routed to the 
interexchange network 1 10, it may be routed to one or more switches within the 
interexchange network. 

If the call is received by an exemplary interexchange network switch 
108 A, the interexchange network switch 108 A will route the call to a bridging 
switch 1 12A. The bridging switch 1 12A will then route The call to the ACD 1 14. 
Alternatively if a bridging switch 112A receives the call, the bridging switch 
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u ^^twnrV switch 108 and the bndging 

swHch , 12 ,«^ fcM— «*■ DMS - 25 ° """^ * 

After the bridging swueu H2 sends the call to the ACD 114, the ACD 

1M communion with «- W» I« • *• •* » ' ^ «~ 

console OA. Ex^nplar, manual operator console 122A aUows • h— 
opontorto hmdleorte individual debited. M«nuu ope«or consoies 122 are 
^ defined in software as being in groups. The BNAP 1M seleas a 
^ operator console 122A and ensures that incoming calls are distnbuted 
among the logic** defined groups. The ACD 114 provides switching 
tatari* between the selected operaor console 122A and tie 

i^chatBe network 110. The ACD 114 cay be implemented using the 
^.OT^ caU distribute* ir^uta^ 

ope^rne^Acen^computersysfcm, The pref«r«d embodiment of the 
present invito includes two «pe«tor nemo* center compu^r svsKms, an 
.pa^rne^c^deareanaworkCWAN) 118 and -<^-*"* 
^.rlocdareanet^rkfLANmO. The operator network center WAN 118 

^opemttrconsolel^ In.ddmon.theop^ center WAN USand 

operaw consoles 122 communicate with the operator network cemcr WAN 

and LAN 120 using UDP/IP. 

Tta .nanual operator consoles 122 are computer consoles that receive 

enre, LAN 120 and provide tie human operator (not shown) v*h the 
irforrntfion . address the debit «* 

network center WAN 118 and the operator network center LAN 120 do not 
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information. 

Ti, SDP 128 acres debit cuaomer account informal used fcr traffic 
i^Utag. ^j-****-*"*""*"*- In accords with*. 

AIN 124 and the SDP LAN 128. In addition, the ATN 124 also pr^pa-ttcol 

..^b^-— «-^^-« ,, ^^ (Iml,,,,,4 

bytheSDP I 28 m d 1 ^da^pro^l^P"t~'< UDr ' I? ^ e4b) ' 
^o.anualop.^consolesm. TlieAIN 124 is described in farther detail in 

stifled "Advanced In«eUi 8 e»t Network Gateway" incorporated by reference 

herein- , . 

Tte select* manual operator console 122A uses infonnanon reserved 

6^ the SDP 128.0 processthecall. Ifthecuaorner is placing a debit call does 
B- b«-»«bl^i-^«»--* ,,, * , -■*"""" ^ * ,,- 

e^rtoc^totheereditcard. At-hori-i.moferedite^ehargesUdon. 
byafrnrfprocessorUt The financial processor 132 is accessed to process 
4. ^ request, referred to tottxcn^eAly herein as a v^danon request, 

via the validation gateway 130. 

The validation gateway 130 translates between UDP/IP used by the 
annual operator consoles 122 and X^5 protocol used by the fu»n^ processor 
132 The validation gateway 130 has a computer program referred to as a 
validation computer program, also referred to as a validation application 
(VALID APPXwhichperfonnsm^ 

for a message to flow between the manual operator console 122A and the 
financial processor 132. VALID.APP includes software modules that mterface 
with the manual operator consoles 122A, perform protocol converse and 
interface with the X.25 network used by the financial processor 132. 
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The preferred embodiment of the present invention performs translation 
between UDP/1P protocol and X.25 protocol. However, the present invention 
may perform protocol conversion between any client server protocol and any 
packet switching network protocol. A client server protocol is a protocol that is 
used by a client server network, such as UDP/IP. A packet switching network 
protocol is a protocol, such as X3.5, that is used by a packet switching network. 
Therefore, the system and method of fee present invention may provide message 
transfer and protocol conversion to any packet switching network protocol and 
is not limited to XJ25 protocol. Although the system and method of the present 
invention is described with regards to X.25 protocol, the term XJ2S protocol 
should be understood to refer to any protocol used by a packet switching network. 

VALH)_APP performs die protocol conversion by building a card request 
message from a validation request message and by building a validation reply 
message from a card reply message. Initially, the manual operator console 1 22A 
sends a validation request message to request authorization to bill to a customer's 
credit card. The validation request message contains transaction data such as the 
customer's credit card account number, the credit card type, the expiration date 
of the credit card, and the amount the customer wishes to charge to the credit 
card. The validation gateway converts the validation request message to a card 
request message which is sent to the financial processor 1 32. When the financial 
processor 132 has determined whether to authorize the transaction, the financial 
processor 132 sends a card reply message to the validation gateway 130* The 
validation gateway 130 performs a similar function of converting the card reply 
message to a validation reply message. The validation gateway then sends the 
validation reply message to the manual operator console 122 A. The present 
invention is not limited to providing a protocol conversion for an authorization 
of a request to bill to a customer's credit card. Therefore, the term card request 
message should be understood to refer to any request message sent by a validation 
gateway 130 to a packet switching network. Likewise, the term card reply 
message should be understood to refer to any reply message received by a 
validation gateway from a packet switching nerwork. The message flow between 
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the manual operator console 122A and the validation gateway 130 will be 
described in more detail in the figures below. 

The financial processor 1 32 is a computer system that includes a database 
thai stores credit card account information for credit card accounts. Merchants 
and companies that accept credit cards purchase the services of a company that 
owns the capability to access financial processors such as exemplary financial 
processor 132. The company or bank maintains credit card information and 
guarantees that a merchant will be paid for an authorized transaction. When a 
request to charge to a customer's credit card is authorized, the merchant receives 
an authorization response code which can be used to ensure that the merchant will 
receive payment for the authorized transaction. When the financial processor 132 
receives a card request message from the validation gateway 130, it either 
authorizes or rejects the transaction and responds with a card reply message to the 
validation gateway 130 including an authorization response code authorizing the 
charges or explaining why authorization was rejected. The flow and format of the 
card request message and card reply message sent between the validation gateway 
130 and the financial processor 1 32 will be described in more detail in the figures 
below. 

After the manual operator console 122A has completed processing the 
call, it releases the call back to the bridging switch 112 via the ACD 1 14. The 
bridging switch 112 connects the call to the receiver 136 via a second local 
exchange network 134. Similar to a first local exchange network 1 06, a second 
local exchange network 134 comprises switches and termination equipment 
within a localized area. The example used in illustrating a first local exchange 
network 106, a local Bell operating company network such as Bell Atlantic, also 
applies to a second local exchange network 134. 

As mentioned previously, a typical call may be processed manually by a 
human operator using a manual operator console 122A or automatically via a 
SSCP 138. The processing of an automated call is similar to that of a call 
processed manually by a human operator in that both calls originate at a telephone 
104, access a first local exchange network 106. and access an interexchange 
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network switch 108 or bridging switch 112 in an intcrexchange network 110. 
However, automated debit calls are not routed to a manual operator console 122A 
viaanACD114,anISNAP 1 1 6, an operator network center WAN 118 and an 
operator center LAN 120. Automated debit calls are routed from the bridging 

5 switch 112 directly to a SSCP 138. 

The SSCP 138 comprises switching and automated response capability. 
The SSCP 138 receives a call from a bridging switch in much the same way as 
the ACD 1 14. However, unlike the ACD 1 14, the call does not need to be routed 
to a manual operator console 122 A. The SSCP 138 has automated response 

1 0 capability that can prompt the caller for the information needed much in the same 

wayasahumanopeiatorofthemanualoperatorconsole. The SSCP 138 receives 
the information from the caller and has the ability to process the call using the 
information. The SSCP 138 may be implemented using an Ericsson AXE- 10 
switched based platform with an automated response unit (ARU) enhancement 

15 Similar to the manual operator console 122A, the SSCP 138 needs debit 

customer account information to process the debit calL Like the manual operator 
console 122A, the SSCP 138 obtains this information from the SDP 128. If the 
SDP 128 indicates that additional funds are needed in a debit account, the SSCP 
138 will prompt the caller to determine if the caller would like to add funds to the 

20 debit account If the caller would like to add funds to the debit account, the SSCP 

138 accesses the financial processor 132 to validate the credit card via the AIN 
124 and die validation gateway 130. 

Because the AIN 124 performs protocol conversion between TCP/IP and 
UDP/IP, the validation gateway 130 performs protocol conversion between 

25 UDP/IP and X,25. Similar to a call processed by a manual operator console 

122A, VALED_APP performs protocol conversion between UDP/IP and X.25 by 
building a card request message from a validation request message and building 
a validation reply message from a card reply message. When the call is processed 
by the SSCP 138, the SSCP 138 sends a validation request message to request 

30 authorization to bill to a customer's credit card. The validation request message 
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r, * . „*ewav 130 is in the same format ar«i contains the 
san* data fields as themes^*.-' ^ , 

^^^^^^^^^ 

telephone 136. on ^ preferably 

The validation gateway 130 of the presem 

?02 as shown in block diagram form in 
indented using a computer system 202 as shown 

-~ «/ct«n 202 includes one or more processors, «»• 
FIG. 2. The computer system 202 in* 04ismammemol y 
lessor 206 connected to bus 204. Also connected to bus 204 ism _ 
processor iuo com- secon dary storage devices 

208 fnreferably random access memory, RAM) anos _ . 

208 (preierao y k & ^ ^ 212 

o i n The secondary storage devices mciuu ♦ 

aid a removable storage meoi ™ m ,h,l resides in n«>hi 

202 (and of the processor 206). AhexnatWely, the VALID.AFP « 
system 202 (.ana U1 U1 * ^ u„„i,.„™- machine. 

L. - ,t,!v or entirely a hardware device, such as a hardware state macmn 

L. mereon. The control logic. vmen loaded into .nun memory 20» and 

^H^us^^m^opetatotcoosole ,22A-ru»ncia, process* 
m meU *~ - »— — ' 

r^ALlD APP, «hi* is the vacation computet program on the vahdat. n 
,30. VAUDJUT. ^^^^ aaA prolocol conversion needed for 
gateway 1 30, performs the message transi 
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ames^etoflowbetwcenmen^anual pentor console 122A and a fuunaal 
processor 132. Prior to describing the manual operator console 122A-financial 
processor 132 message flow 302, an overview of the message flow between the 
manual operator console 122A and the financial processor 132 is provxded 
bigbnghtingthef^^ of the VALID_APP 

computer program. 

The manual operator console l22A-financial processor 132 message fk™ 

302 comprises a two part transaction including: (1) an authorization request sent 
from the manual operator console 122Ato the financial processor 132 and (2) a 
reply, with an authorization objection, fo,mmefinaneial processor 132 to the 
xnanual operator console 122A. Multiple software modules included in the 
VALID APP computer program interface with the manual operator console 
122A, perform protocol conversion between UDP/IP used by the manual operator 
console 122A and )C25 pro"* 01 ^ ^ P roccssor ' md ~ mtedaCe 

with the X-25 network used by the financial processor 132. 

VALID APP includes a client receive module referred to as the user 
datagram protocoWntemet protocol receive (UDP.RECV) module and a client 
send module referred to as the user datagram protocol/internet protocol 
(UDP_SEND) module that interface with the manual operator console 122A. A 
client receive module is a vahdation computer program module that receives 
requests from clients, such as caller interaction processors. A client send module 
is a vaUdation computer program module that sends replies to clients. The 
UDP RECV module accepts requests for authorization of credit card charges 
fmm^nanual operator consoles 122. The UDP_SEND module sends responses, 
including authorization or rejection of the credit card charge, received from the 
financial processor 132 to the manual operator consoles 122. Both TJDP_RECV 
and UDP_SEND are single points of interface for all manual operator consoles 

122 and for the SSCP 138. 

V ALE)_APP also includes a validation module referred to as a validation 
process (VALIDJROCESS) module. A validation module is a validation 
computer program module that performs protocol conversion needed for message 
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transfer between clients and processors. The VALID_PROCESS module 
performs protocol conversion needed for communication between the manual 
operator console 122A and the financial processor 132. When the UDPJUECV 
module receives a validation request message requesting authorization of credit 
card charges from the manual operator console 122A, VALID_PROCESS builds 
a card request message to send to the financial processor 1 32. When the financial 
processor 132 sends a card reply message either authorizing or rejecting charges 
associated with a particular transaction, VALID_PROCESS builds a validation 
response message to send via the UDP__SEND module to the manual operator 
console 122A. 

An additional module within the VALID_APP computer program is a 
communications module referred to as X.25 communications process (X25 
COMMJPROCESS) module. A communications module is a validation 
computer program module that interfaces with a packet switching network, such 
as the X25 network. A communications module is not limited to interfacing with 
an XJZ5 network but may interface with a processor via any packet switching 
network. The X.25 COMMJPROCESS module interacts with the financial 
processor 132. The X.25 COMMJPROCESS module sends card request 
messages to the financial processor 132. In addition, the X.25 
COMMJPROCESS module forks out a child process which accepts card reply 
messages, with an authorization or rejection, from the financial processor 132. 
When a module foxks out another module, the initial module, also referred to as 
a parent module, temporarily creates the second module, also referred to as a 
child module. The second module is typically temporarily created to handle a 
particular transaction and then exits so that one module, the parent module, 
remains. 

In step 306, the manual operator obtains a validation request to bill to the 
customer's credit card account The customer calling on a telephone 104 is 
received by a manual operator console 122A as described above. A human 
operator operates the manual operator console 122A. The human operator 
collects transaction data from the customer. Transaction data is any data needed 
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by the processor to perform the transaction. Transaction data to perform a 
customer request to charge to a credit card includes a customer credit card 
number, credit card type i.e.. Visa, MasterCard, American Express, and expiration 
date. Transaction data may also include the customer' s address or zip code for 
verification. In addition, an authorization amount which is the amount to be 
billed to the customer's credit card is provided by the customer and is included 
m transaction data. The human operator enters the transaction data obtained from 
the customer in the manual operator console 122A. 

In step 308, the manual operator console 122A sends a validation request 
message to the validation gateway 130. The manual operator console 122A 
populates fields in a vaUdation request message, also referred to interchangeably 
heremasarequestiirfOTmation message, wim me transaction data obtained by the 
customer. The format for the vaUdation request message is referred to as request 
information message format and is shown in Table 1 below. 

The validation request message includes fields, referred to as validauon 
request fields, that are populated with transaction data to identify the call, the 
customer, and the merchant. The request information message format includes 
a field referred to as achMerchantID which is 16 characters. The achMerchantID 
field is populated with a merchant identifier and a customer credit card account 
identifier. A merchant identifier identifies the merchant that is providing the 
services that the customer is paying for using his or her credit card. The customer 
credit card account identifier, referred to interchangeably herein as a customer 
credit card account number, is typically a number 11-15 digits long that identifies 
a customer credit card account. In addition, the request information message 
format includes a 2 character achCardType field which is populated with the type 
of credit card the customer is using, a 4 character achExpDate field which is 
populated with the expiration date of the customer credit card, and a 9 character 
achZipCode field which is populated with the customer's zip code. The request 
information message also includes an authorization amount field entitled 
achAuthAmtLong which is 9 characters and is populated with the amount 
authorized by the customer. 



WO 99/21096 



19 



PCT/US98/22267 



Additional transaction data included in the validation request fields of the 

the telephone number that the customer called from which is referred to as the 
call from number. The call from number fa populated in the 16 character 
achCallFromNumber field. Another example of transaction data is the number 
the customer is calling, also referred to as the called to number, which is 
populated in the 16 character achCaUToNumbcr field. Additional transaction 
data is populated in the validation request fields of the validation request message 
as is shown in Table 1 below. 



HequestJnfo 



chPcktType 
achReqType(2) 

achNumber(24) 



achPin(4) 



chExpDate(4) 



achAuthAmt(4) 



TABLE 1 



DEFINITION 



Type of validation packet 0-Req 1-Res 2-Force 

validation type 0-BOC 1-ColIect 2-Third party 
3-Bankcard 4-Vnet 5-ICCN 6-ANET 

phone # or cant U (tnincaled to 22 in pack jelic) 



Personal Id Number 



expiration date 



authorization amount 



achConsNum(3) 



achSitcNum(2) 
achResponse(4) 



achZipCode(9) 



old console number 



old site number 
response from validator 



Customer zip code 



achCallFromNumber(16) 



Number customer is calling from 



achCaltToNuraber<l 6) 



Number customer is calling to 



achCardType(2) 



Credit card coll type Visa, etc. 



achAuthCode(6) 



Authorization code from NDC 



achAuthCenter(2) 



Source of Authorization code 



chPosIndicator 



Point of access indicator 



achCustSubAcctNum(lO) 



Customer sub account number used for billing 
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request-Info 


DEFINITION 


achServProvIDM) 


Service Provider ED 


c Q <>rvi ei*Tvn c 


Type of service provider 1-VALL1DB1 
2-VALUDB2 3-VALCSJ 4-VALNDC 5-VALDAP1 
6.VALDAP2 7-VALHKT 8-VALICCN 
9-VALCARDTEL 10-VALAOCT 1 1-VALBT 
12-VALGlOBAL 16-vALCX-AUv i /- v m*y~uru.s\. i 


chMsgTypc 


Message Type of DAP type requests 


achSwitchID(3) 


Switch ID 


achTnickGroup(5) 


Trunk Group 


chANINatureofCall 


ANI nature of call for DAP validation 


chAddressNatCfCali 


Address Digit nature of call for DAP validation 


chRestrictlndicator 


Provides nature of card restriction 


chServiceldentifier 


Indicates service for which card is being charged 


chDapAetionCode 


Action code response from DAP 


chDapDividACIFCodc 


ACEF code response from DAP 


chAMACode 


AMA Code used m OSR billing 


achReservedl(S) 


Future use 


achReserved2(3) 


Future use 


chSuppCodeLength 


Binary field which is num of supp code digits 


achSuppCodc(35) 


Used in ONAT call request and Supp Code Resp 


achBusinessGroup(7) 


Used in ONAT call request and Supp Code Resp 


chNatSubAddress 


Nature of Address Indicator found in sub addr 


achSubAddress(30) 


Used in Supp Code Resp packet 


achRoutingInfo(2) 


Binary number used in Supp Code Kesp pacicet 


achFartitionNum(2) 


pi nBPU nnmKpr \\*p>A in Sunn Code Reso oacket 
Binary nuuiuci lucu m ^ M^tyt 


chNoAnswcrTimcr 


Binary number used in Supp Code Resp packet 


achNCSIntb(30) 


Used in Supp Code Resp packet 


achTenninationID(15) 


Used in Route Resp packet 


achConsNumLong(4) 




achSiteNumLong(3) 
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Request-Info 


DEnwrnoN 


achMerchantID(I6) 


NEW FIELD - MERCHANT ID 


achAuthAmtLong(9) 


LARGER AUTHORIZATION AMOUNT FIELD 
FOR ANSWERNET 



In step 310, the validation gateway 130 converts the validation request 
message from a client server protocol to X25. In this case, the client server 
protocol used by the manual operator console is UDP/IP. 

The protocol conversion is performed by multiple software modules of the 
VALID_APP computer program on the validation gateway 130. The validation 
request message is received by the UDP_RECV module of the VALID_APP 
computer program. The UDP_RECV module sends the validation request 
message to the VALIDJ'ROCESS module which performs conversion from 
UDP/IP to X^5. The protocol conversion is performed by VALID_PROCESS 
building card request message to send to the financial processor 132. Further 
details of the protocol conversion and function of the software modules of the 
VALID_APP computer program are illustrated in FIG. 4. 

In step 312, the validation gateway 130 sends the card request message 
from the validation gateway to the financial processor 132 for authorization to 
charge to the customer's credit card account. The X.25 COMM_PROCESS 
module sends card request messages to the financial processor 132. In addition, 
the X25 COMMJPROCESS module forks out a child process which accepts card 
reply messages, with authorization data which is an authorization or rejection, 
from the financial processor 132. 

Although the X.25 COMMJPROCESS module is the primary module 
used for sending card request messages, the process of sending the message from 
the communications module involves several modules that are forked out from 
the X.25 COMM_PROCESS module. The process of sending card request 
messages varies depending on whether the card request message is sent over a 
permanent virtual circuit or switched virtual circuit. A permanent virtual circuit 
is initialized upon system startup and remains as a permanent link between the 
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vaUdationgateway 130 and an node (nrtshovm) on the X25 network -hich 
interconnects the validation gateway 130 to the financial processor 132. A 
permanent virtual circuit remains as a permanent link until the system is 
shutdown. A switched virtual circuit is initialized when a card request message 
is initiated and terminated upon transmission of the validation response message, 
which completes the particular validation transaction. 

If a permanent virtual circuit is used to transmit a card request message, 
the X.25 COMM.PROCESS module sends the card request message via the 
permanent virtual circuit on the X.25 network to the financial processor 1 32. 

If a switched virtual circuit is used to tnmsxmt a (^request message, the 
3C25 COMM.PROCESS forks outaX25 service out module. The X25 service 
out module requests an X.25 link from the X.25 network that can provide 
interconnection with the financial processor 132. The X.25 COMM.PROCESS 
sends the card request message to the X^5 service out module. The X.25 service 
out module sends the card request message to the financial processor 132 via the 
switched virtual circuit provided on the X.25 network. 

In step 314, the financial processor 132 sends a card reply message to the 
validation gateway 130. The validation gateway 130 receives the card reply 
message in the communications module of the VALIDAPP computer program 

on the validation gateway 130. 

If a permanent virtual circuit was used to transmit the card request 
message, the card reply message is received on the same permanent virtual 
circuit Thceamxeplymessageisiece^^ Tbc 
XJ25 COMM.PROCESS sends the card reply message to VALID.PROCESS. 

If a switched virtual circuit is used to transmit a card request message, the 
card reply message is received on the same switched virtual circuit The card 
reply message is received by the X25 service out module. The X.25 service out 
module sends the card reply message to VALID.PROCESS. The X.25 service 
out module also sends a response received message to the X.25 
COMM.PROCESS. The X.25 service out module is used only for a particular 
validation transaction. 
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In step 316, the validation gateway 130 converts the card reply message 
from the X.25 protocol to the client server protocol VALIDAPP receives the 
card reply message from the financial processor in the communications module. 
The communications module sends the card reply message to the 
V ALIDJPROCESS module to perform protocol conversion. VALID JPROCESS 
builds a validation response message and sends the validation response message 
toUDP SEND. Further detail of die protocol conversion and function of the 
software modules of the VALID_APP computer program is illustrated in FIG, 5. 

In step 318, the validation gateway 130 sends a validation response 
message to the manual operator console 122A. The validation response message 
includes an authorization response code which the manual operator console 122 A 
uses to determine if the customer is authorized to pay for the amount requested 
using the credit card. The operator enters information into the manual operator 
console 122A to send a message to the SDP 128 to update the customer's account 
to the new amount the customer can use for prepaid calling. 

FIG. 4 illustrates in more detail the conversion from a client server 
protocol to a X.25 protocol 310. In the preferred embodiment of the present the 
conversion the protocol conversion that is performed is between UDP/IP and 
5C25. 

In the preferred embodiment of the present invention, the validation 
gateway 130 interfaces with either a manual operator console 122A or the AIN 
124 that communicates with the SSCP 138. Both the manual operator console 
122A and the AIN 124 communicate with the validation gateway 130 using 
UDP/IP. Although the SSCP 138 uses TCP/IP, the AIN 124 performs a protocol 
conversion between TCP/IP and UDP/IP. Therefore, the validation gateway 130 
communicates with both types of caller interaction processors, the manual 
operator consoles 122 and the SSCP 138, using UDP/IP. As a result, the client 
server protocol in the preferred embodiment of the present invention is UDP/IP 
regardless of whether the caller interaction processor is a manual operator console 
122A or the SSCP 138. In addition, the protocol conversion is performed as is 
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described with respect to FIG. 4 regardless of whether the call is received fiom 
the manual operator console 122A ox the SSCP 138. 

In step 406, the vatidation request message is received by the client 
receive module of the VALID.APP computer program. The client receive 
module is the module within the VAIID_APP that receives validation messages 
from the caller interaction processors such as the manual operator consoles 122 
of the SSCP 138. The client receive module is referred to as UDP_RECV when 
it is specialized for receiving messages fiom client server networks using UDP/IP 
protocol as in this case. The UDP_RECV module is a single interface point for 
all caller interaction processors including the manual operator consoles 122 and 
the SSCP 138. The UDP_RECV module receives validation request messages 
from both types of caller interaction processors, the manual operator consoles 122 
and the SSCP 138. 

In step 408, the validation request is sent to the validation module, also 
referred to as VALIDPROCESS of the VALIDAPP. VALID.PROCESS 
receives the validation request message in the request information format 
described in Table 1 fiom the client receive module. VALID_PROCESS creates 
a card request message, using data in the validation request message. The card 
request message is in a format that can be understood by the financial processor 
132. 

In step 410, VALID_PROCESS retrieves the transaction data fiom the 
validation request fields of the validation request message. The transaction data 
includes the merchant identifier and customer credit card account identifier 
retrieved fiom the ach Merchant ID field, the type of credit card the customer is 
using retrieved fiom the achCardType field, the customer credit card expiration 
date which is retrieved fiom the achExpDate field, the customer's zip code 
retrieved fiom the achZipCode field, and the amount the customer authorizes to 
bill to the credit card retrieved fiom the achAuthAmt field. The transaction data 
also includes the number that the customer called to which is retrieved from the 
achCallToNumber field and the number the customer called from which is 
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retrieved the achCallFrx.mNumber field. Additional transaction data is retrieved 

as is shown in Table I above. 

In step 412 VALID PROCESS stores the transaction data in a local 
message pending UsL A local message pending list is a series of addresses 
^ciatedwithmemory^ VALID.PROCESS 
stores the transaction data in the local message pending list while create the 
card request message in that format that can be sent to the financial processor 

132. 

In step 414, VALIDPROCESS builds a card request message. Because 
the validation request message cannot be understood by the financial processor 
1 32, the V ALIDPROCESS builds a card request message that can be understood 
by the financial processor 132. The card request message includes the fields 
achCardType of 2 characters that is populated with the type of credit card, the 
acbMerchamID field of 16 characters that is populated with the merchant 
identifier and the customer credit card account identifier, and the achExpDate 
field of 4 characters that is populated with the expiration date of the customer's 
credit card. The card request message also includes the achCallToNutnber field 
of 16 characters which is populated with the called number and the 
achCallFromNumber field of 1 6 characters which is populated with the number 
called from. Additional fields are included in the card request message as shown 
in Table 2 below. 
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Table 2: card request 


Request-Info 


DEFINmON 


achMessageID(3) 


Constant = "TBI" 


achReferenceNum(6) 


2 most significant chars - NDC use, 4 least significant 
chars - our use 


aehCardNuxn(22) 


Card or Phone Number. Left justified and space 
filled 


achExpDate(4) 


xyTVfYY format 


byPOSIndicator 




achAcquinngICA(6) 


d Wiait TP A number with trailing zeroes 


achTransCode(2) 


(~/\nctont - "T* 1 ^tplenhone Transaction) 


achAmtOfTrans(9) 


yyyyyyyvy mpanc YYXXXXX dollars and YY 
cents 


byFiller 


Space filled 


achMcrchantID(lo) 


D?*iti+ Sitc+i£t»/4 7f»nri filled 


achCardType(2) 


7 rii<rit code ner ADDondix B 


achTOTiTtmcDate(10) 


HHMMSSMMDD blank if unavailable 


achCustRefNum(8) 


Assigned by Customer, blank if unavailable 


achAuthCenter(2) 


Authorization Center, e.g., "DC" 


achDiscData(24) 


Discretionary Data. Spacefilled 


achPINBlock(l6) 


Optional. Cardholder PIN ANSI Block. Left 
Justified, space filled 


achProductCode(28) 


Optional. Left Justified, Zero filled 


achAddVerData(29) 


Address Verification Data, Optional 

First 9 positions « 9 digit ZIP or 5 digit ZIP + 4 

spaces Remaining * first 20 chars of address, LJSP 


achCaHToNumbcr(16) 


Used by FPS to screen 


achCallFromNurabcr(16) 


fraudulent calls 



In step 416, VALIDPROCESS sends the card request message to a 
communications module referred to as X.25 COMMPROCESS of the 
VALID_APP. The X.25 COMM_PROCESS sends card request messages to the 
financial processor 132. The X.25 COMMPROCESS is a single point of 
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interface for sending card request messages from the validation gateway 130 to 
the financial processor 132. The XJ25 COMMPROCESS sends card request 
messages as was described in step 3 12 of FIG. 3. 

FIG. 5 illustrates the conversion from 5C25 protocol to a client server 
protocol. 

In step 506, the validation gateway 130 receives a card reply message 
from the financial processor 132 in the X.25 COMMJPROCESS module of 
VALID_APP. The process for receiving a card reply message is described in step 
3 14 of FIG. 3. 

In step 508, the X25 COMMPROCESS module sends the card reply 
message to VAUDPROCESS. VAUDPROCESS converts the message from 
a card reply message to a validation response message. In addition, similar to 
sending a message from the manual operator console 122 A to the financial 
processor 132, when a message is sent from the financial processor 132 to the 
manual operator console 122 A, VAUDj>ROCESS converts the message from 
X35 to the client server protocol, UDP/IP. The format for the card reply message 
is provided in Table 3 below. 



Table 3: card Reply 


Reply-Info 


Definition 


achMessageID(3) 


Constant =T03 n 


achReferenceNum(6) 


Transaction reference number 


achRevQueNumber(6) 


Key to reversal queue entry. If blank, transaction 
is not eligible for reversal 


byRespCode 


Response code per appendix B 


achAuthcode_RejectReason(6) 


Authorization code (if approved) or rejection 
reason code (if rejected) 


achEDCJulianDay(3) 


If approved, date returned 


achActQualifier(3) 


blank 


AchTerm TimeDate( 1 0) 


blank 


AchCustRe£Nura(8) 


blank 
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REfLV-lNFO 



acbNdcSeqNum(6) 



achCumTotal(lO) 



DEFINITION 



blank 



blank 



achActNum(22) 



blank 



byAddrVerResult 



1 char code resulting from address verification 



byAuthSrcCode 



Authorization source code 



byPOSIndicator 



'C* = Swiped, T = Manually keyed, ' ' = none 



In step 510, VAUDPROCESS retrieves authorization data from the card 
reply message. Authorization date is either an authorization code or a reject 
reason code corresponding to a reason for the rejection. If the authorization is 
approved, an authorization code is retrieved front the achAuthcode_RejectReason 
field which is 6 characters. If the authorization was rejected, a reject reason code 
corresponding to the reason for the rejection is retrieved from the 
achAuthcode.RejectReason field which is a 6 character field. Additional 
authorization data includes the authorization source code which is contained in 

the byAuthSrcCode field. 

In step 512. VALIDJPROCESS maps the reply data retrieved from the 
card reply message to an authorization response code. The manual operator 
console 122A cannot process the authorization code and the reject reason code. 
The financial processor 132 has the capability to provide many authorization 
codes and response codes that are useful in various different applications. 
However, the manual operator console 122A needs less specificity in the reason 
for the authorization or rejection to process the call. VALIDPROCESS has a list 
of response codes that can be understood by the manual operator console 122A 
or SSCP 138. VALID.PROCESS maps either the authorization code or the 
reject reason code to an authorization response code. An authorization response 
code can be understood by the manual operator console 122A or the SSCP 138 
and provides information indicating whether the transaction was authorized, and 
if not, the reason for the rejection. 
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In step 514, VALID JPROCESS retrieves transaction data from the local 
message pending list VALIDJPROCESS stored transaction data in the local 
message pending list during the processing of the validation request message sent 
from the manual operator console 122A. 

In step 516, VALIDJPROCESS builds a validation response message 
using the transaction data retrieved from the local message pending list and the 
response coda In step 412 of FIG. 4, VALIDJPROCESS stored the transaction 
data in a local message pending list VALID_PROCESS now retrieves the 
transaction data from the local message pending list VALIDJPROCESS builds 
a validation response message using the retrieved transaction data and the 
authorization code obtained in step 514. 

In step 518, VALIDJPROCESS sends the validation response message 
to the client send module. The client send module is capable of sending messages 
to client server networks such as the operator service network. In this case the 
client send module is referred to as the UDP_SEND module because the client 
server protocol is UDP/IP. The UDPJJEND module is a single point of interface 
for sending validation response messages to caller interaction processors. The 
UDP_SEND module sends validation response messages to both the manual 
operator consoles 122 and the SSCP 138. 

FIG. 6 illustrates the SSCP 138 financial processor 1 32 message flow 602. 
The SSCP 138 sends a message to the financial processor 132 via the AIN 124 
and the validation gateway 130. The AIN 124 provides translation between 
TCP/IP used by the SSCP 1 3 8 and UDP/IP used by the manual operator consoles 
122. The conversion process of the AIN 124 is described in further detail in US. 
Patent Application Attorney Docket No. CDR-96-009 (1575.2240000), entitled 
"Advanced Intelligent Network Gateway" incorporated by reference above. The 
validation gateway 130 translates between user UDP/IP used by the manual 
operator consoles 122 and X.25 protocol used by the financial processor. 

In step 606, the SSCP 138 obtains a customer request, referred to as a 
validation request, to bill to the customer's credit card account. The customer's 
call is received by a SSCP 138 as described above. The customer enters 
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transaction data using the keypad f the telephone 104. The SSCP 138 collects 
transaction data from the customer. Transaction data includes a customer credit 
card number, credit card type i.e., Visa, Mastercard, American Express, and 
expiration date. Transaction data may also include the customer's address or zip 
code for verification. In addition, an authorization amount which is the amount 
to be billed to the customer's credit card is provided by the customer and is 
included in transaction data. 

In step 608, the SSCP 138 sends a validation request message to the 
validation gateway 130. The SSCP 138 sends the validation request message to 
the validation gateway 130 after querying the SDP 128. In order to allow a 
customer to establish a prepaid call, the SSCP 138 queries the SDP 128 to 
determine if the customer has sufficient funds in his or her prepaid card account 
to place the call. If the customer has insufficient funds, the SSCP 138 gives the 
customer the option to add funds using a credit card. If the customer selects to 
add funds to his or her prepaid card account using a credit card, the SSCP 138 
collects the transaction data and sends the validation request message. 

The SSCP 138 sends the validation request message to the AIN 124 for 
conversion from TCP/IP protocol to UDP/IP protocol. After converting the 
validation request message from TCP/IP protocol to UDP/IP protocol, the AIN 
124 sends the validation request message to the validation gateway 130. 

The validation request message sent from the AIN 124 to the validation 
gateway 130 is in the same format and contains the same information as the 
validation request message sent from the manual operator console 122A to the 
validation gateway 130 described in FIG. 3. As with the validation request 
message sent from the manual operator console I22A, the validation request 
message sent from the AIN 124 contains transaction data obtained from the 
customer. Like the validation request message sent from the manual operator 
console 122A, the validation request message sent from the AIN 124 includes a 
16 character achMerchantID field which is populated with a merchant identifier 
and a customer credit card account identifier, referred to interchangeably herein 
as a customer credit card account number. The merchant identifier identifies the 
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merchant that is providing the services that the customer is paying for using his 
or her credit card account The customer credit card account number identifies 
a customer credit card account Also, like the validation request message sent 
from the manual operator console 122A, the validation request message sent from 
the AIN 124 includes a 2 character achCardType field which is populated with 
the type of credit card the customer is using, a 4 character achExpDate field 
which is populated with the expiration date of the customer credit card, and a 9 
character achZipCode field which is 9 populated with the customer's zip code. 
In addition, like the validation request message sent from the manual operator 
console 122A, the validation request message sent from the AIN 124 includes an 
authorization amount field, achAuthAmtLong, which is 9 characters and is 
populated with the amount authorized by the customer. 

Like the validation request message sent from the manual operator 
console 122A, the validation request message sent from the AIN 124 also 
contains additional transaction data used in processing the call. In the preferred 
embodiment of the present invention, the transaction data used for call processing 
in the validation request message sent from the SSCP 138 is the same as the 
transaction data used for call processing the is sent in the validation request 
message from the manual operator console 122A. Both the call from number and 
the call to number are populated in the validation request message from the AIN 
124. The call from number is populated in the 16 character achCaUFromNumber 
field The call to number is populated in the 16 character achCallToNumber field 
Additional transaction data is populated in the validation request message as is 
shown in Table 1 above. 

In step 610, the validation gateway 130 converts the validation message 
from a client server protocol to a X2S protocol. Similar to processing validation 
request messages sent from the manual operator console 122A, VALID_APP 
performs the protocol conversion. The process for protocol conversion is the 
same for messages sent from the manual operator console 1 22 A and the SSCP 
138. The process for converting from a client server protocol to a X.25 protocol 
is described in FIG. 4. 
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In step 612, the validation gateway 130 sends a card request message to 
the financial processor 132 for authorization to charge to the customer's credit 
card account. Similar to processing a request sent by a manual operator console 
122A, the financial processor 132 authorizes or rejects the transaction using 
customer account information stored in a database. Similar to processing a 
request that originated from the manual operator console 122A, a card request 
message resulting from a request by the SSCP 138 may be sent to the financial 
processor 132 on a permanent virtual circuit or a switched virtual circuit on the 
X.25 network. The process for sending a card request message from the 
validation gateway 130 is the same whether the request originates from a manual 
operator console 122A or a SSCP 138. Both the process for sending a card 
request message from the validation gateway-130 to the financial processor 132 
on a permanent virtual circuit and the processor for sending a card request 
message on a switched virtual circuit are described in step 3 12 of FIG. 3. 

In step 614, the financial processor 132 sends a card reply message to the 
validation gateway 130. Similar to the processing of a request originating from 
a manual operator console 122A, the validation gateway 130 receives the card 
reply message in the communications module of VALID.APP- Like processing 
a request from a manual operator console 122A, the card request message is 
received by a child X25 COMMPROCESS if a permanent virtual circuit was 
used and by an X.25 service out module if a switched virtual circuit was used. 
The process for receiving card reply messages is the same regardless of the type 
of originating or terminating caller interaction processor. The process for 
receiving a card reply message is described in further detail in step 314 of FIG. 3. 

Instep616, the validation gateway 130 converts the card reply message 
from X.25 protocol to the client server protocol. Like processing requests 
originating from and terminating to a manual operator console 122A, 
VALID_APP performs a protocol conversion from the X.25 protocol to the client 
server protocol for requests originating form and tenninating to an SSCP 138. 
Also, like processing requests originating from and tenninating to a manual 
operator console 122A, the client server protocol is UDP/IP because the AlN 124 



WO 99/21096 33 PCTAJS98/22267 



converts from TCP/IP used by the SSCP 138 to UDP/IP. Further detail of the 
protocol conversion is illustrated in FIG. 5. 

In step 618, the validation gateway 130 sends a validation response 
message to the SSCP 138. Like a validation response message sent to a manual 
5 operator console 122 A, the validation response message to the SSCP 138 includes 

an authorization response code which the SSCP 138 uses to determine if the 
customer is authorized to pay for the amount requested using the credit card. If 
the customer is authorized to charge the requested amount, the SSCP 138 sends 
message to update the database in the SDP 128 to reflect in the customer's 

1 0 account the new amount that the customer can use for prepaid calling. 

In step 620, the validation gateway 130 writes a non-billable billing data 
record (BDR). The present invention allows settlement to be complete when the 
credit card authorization is complete. Settlement refers to completion of 
processing needed to bill the customer. In prior art systems, settlement was 

1 5 complete when a BDR was combined with an OSR (operator service record) and 

was processed by billing systems. An OSR contains call time and other call 
related information and is written by a switch upon completion of a call. A BDR 
contains credit card information and is written by a manual operator console 
122 A. Although settlement is complete when credit card authorization is 

20 complete in the present invention, the BDR and OSR are written and sent to 

notify billing systems that settlement is complete. 

When the call is handled by an SSCP 138, the validation gateway 130 
sends a request for downstream systems to write a non-billable BDR that contains 
the credit card information. In order to process both calls from manual operator 

25 consoles 122, that do not have non-billable BDRs written by the validation 

gateway 1 30, and the SSCP 1 3 8, that does have a non-billable BDR written by (he 
validation gate 130, the validation gateway must be able to determine which type 
of caller interaction processor sent the call. The validation gateway does not 
write a non-billable BDR for calls processed by the manual operator console 

30 122A because the non-billable BDR is written by the manual operator console 

122A after the validation response message is received. 
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The chServiceldentifier field of the validation request message is used by 
the validation gateway 130 to determine whether the call was sent by a manual 
operator console 122A or an SSCP 138. If the chServiceldentifier field is 
populated with a 1, the call was sent from the SSCP 138 and the validation 
gateway 130 writes a non-billable BDR. If the chServiceldentifier field is 
populated with a 0, the call was sent from a manual operator console 122A and 
the validation gateway 130 does not write a non-billable BDR. 

After die validation gateway 130 receives the validation request message, 
the validation gateway 130 stores information received in the validation request 
message, including the 0 or 1 populated in the chServiceldentifier field, in a local 
message pending list Storing of information in the local message pending list 
was described in step 412 of FIG. 4 which applies to processing a call from both 
the manual operator console 122A and the SSCP 138. When the validation 
gateway 130 receives a card reply message from the financial processor 132, the 
validation gateway retrieves the transaction data, including the 0 or 1 that was 
populated in the chServiceldentifier field, from the local message pending list. 
The validation gateway 130 determines whether a non-billable BDR must be 
written based on whether the chService Identifier field is populated with a 0 or 
al. 

If the chService Identifier field was populated with a 1 , after the validation 
gateway 130 sends a validation response message to the SSCP 138. the validation 
gateway 130 writes a non-billable BDR. A key word in a validation configuration 
file is used to start the process to write non-billable BDRs. Writing a non-billahle 
BDR by the validation gateway 130 involves the validation gateway 130 sending 
a BDR write request to the BDR database server 1 40 and receiving a BDR write 
response from the BDR database server. Hie process for writing non-billable 
BDRs is described in further detail in FIG. 7. 

In step 622, the validation gateway 1 3 0 sends the BDR write request to the 
BDR database server 140. The BDR database server 140 contains a database that 
stores non-billable BDRs. The non-billable BDR is written to that database. A 
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network information distribution service (NIDS) database server configuration 
file is used to determine to which BDR server 140 to write the non-billable BDR- 

FIG. 7 illustrates creating a BDR by a validation gateway 130 message 
flow 702. The validation gateway 130 writes a BDR for a validation request 
originating from an SSCP 138. As discussed in step 620 of FIG. 6, the validation 
gateway 130 determines that the validation request originated from an SSCP 138 
if the chServiceldentifier field is populated with a 1. Additional details of the 
process for determining whether the validation request message originated from 
an SSCP 138 are provided in step 620 of FIG. 6. 

In step 706, the validation gateway 130 writes a BDR write request The 
BDR write request is sent by the VALIDJPROCESS module of the VALID_APP 
computer program on the validation gateway 130. As mentioned, a BDR contains 
credit card information and is used by billing systems to determine that settlement 
is complete* The BDR write request is a request to the BDR database server 140 
to write a non-billable BDR. 

In step 708, the VALIDJPROCESS module sends the BDR write request 
to the non-blocking application(NBAPP) module. The credit card information 
needed to write the BDR is sent in the BDR write request The NBAPP module 
is forked out by the VALIDJPROCESS module to act as an interface from the 
VALIDJPROCESS module to a client process module (CLPROC), The NBAPP 
module is a validation computer program module that acts as a single point of 
interface for all messages transferred between the VALIDJPROCESS module and 
the CLPROC module. The NBAPP module ensures that messages sent between 
the VALIDJPROCESS module and die CLPROC module do not block by 
monitoring the message and providing timing. 

In step 710, NBAPP sends the BDR write request to CLPROC. The BDR 
database server 140 is part of the network information distribution service 
(NIDS). NIDS is a computer system that is also part of an interexchange network 
110 and is used to perform various call processing functions for 
telecommunications services. NIDS uses a prot coi referred to as Network 
Information Distribution Service (NIDS) Sequenced Packet Protocol (NSPP) 



WO 99/21096 



PCTAJS98/22267 



protocol. Because the BDR server 140 needs the BDR write request to be in a 
format compatible with NSPP, the CLPROC module packages the BDR write 
request for NSPP. The CLPROC module is the validation computer program 
module that provides the NSPP interface which includes timing, packaging the 
5 message, and waiting for a response. Packaging the message in a format that can 

be understood by NSPP includes converting the protocol of the message, parsing 
the message, and converting the headers of the message* 

In step 712, the CLPROC module sends die BDR write request to a BDR 
service. The BDR service is the computer program on the BDR database server 

10 1 40 which collects BDRs to send to downstream systems for billing. In this case, 

because the BDR is for a credit card transaction, no billing is necessary. 
Settlement needed to bill the customer is completed at the time of authorization 
of the credit card charges by the financial processor. As a result, the BDR service 
creates a non-billable BDR to show that settlement has been completed. The 

15 BDR is referred to as a non-billable BDR because no billing results Scorn the 

BDR. 

In step 714, the BDR service writes the non-billable BDR. The non- 
billable BDR is stored in a database on the BDR server 140. The non-billable 
BDR is processed by billing systems similar to other BDRs, however, no billing 

20 results from the processing of a non-billable BDR. The non-billable BDR merely 

provides information that indicates settlement is complete. 

In step 7 1 6, the BDR service sends a BDR write response to a demultiplex 
process (DEMtKPROCESS) module. The DEMUX_PROCESS module acts 
as a single point of interface for validation requests from various customers. The 

25 DEMUX_PROCESS module is the validation computer program module thai 

manages the packets received from the BDR service on the BDR database server 
140 and ensures that packets are identified based on the client that sent the 
request The DEMUXJPROCESS module determines which validation request 
is associated with a particular packet received from the BDR service. The 

30 DEMUX ^PROCESS module sends the packet to a response queue corresponding 
to the customer that the request was received from. The BDR write request is a 
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message that responds indicating whether the non-biUable BDR was successfully 
written by the BDR database server 140. 

Instep718,theDEMUXJ>ROCESS module sends a BDR write response 
to the CLPROC module. The CLPROC module acts as an interface for sending 
the message to the NBAPP module. Again, the CLPROC module provides 
timing and packaging of the message. 

In step 720, the CLPROC module sends the BDR write response to 
NBAPP. NBAPP again acts as an interface between VALID_PROCESS and 
CLPROC. 

In step 722, the NBAPP sends the BDR write response to the 
VALEDPROCESS module. When the VALID_PROCESS module receives the 
BDR write response, writing of the non-billable BDR is complete. 

FIG. 8 illustrates the message flow for validating a request message 
received on an X25 permanent virtual circuit. The validation gateway 130 
receives a request from the 3C25 network to validate a card issued by the 
telephone company. Examples of cards issued by a telephone company are 
calling cards, prepaid cards, and international calling cards. The cards are 
validated by computer systems on the telecommunication network. Requests to 
validate these cards may come from apacket switching network, such as the X.25 
network, and protocol conversion is needed to enable the computer systems on 
telecommunications network to process the request 

Similar to requests sent from the validation gateway 130 to the packet 
switching network, requests sent from the packet switching network to the 
validation gateway 130 comprise a two part transaction including: (1) a request 
sent from the packet switching network to a telephone company card database and 
(2) a reply, with an authorization or rejection, from the telephone company card 
database to the packet switching network. The same software modules of the 
validation computer program VALID_APP are used to perform the protocol 
conversion from X.25 and the client server protocol used by the telephone 
company. 



WO 99/21096 



38 



PCT/US98/22267 



Also, similar to requests sent from the validation gateway 130, the present 
invention is not limited to providing a protocol conversion for an authorization 
of a request to use a card issued by a telephone company. The present invention 
may be used for protocol conversion for any request sent from a packet switching 
network to a client server network. Therefore, the term telephone card request 
message should be understood to refer to any request message sent by a packet 
switching network to a validation gateway 130. Likewise, the teim telephone 
card reply message should be understood to refer to any reply message sent from 
a validation gateway 130 to a packet switching network. 

In step 806, the XJ25 COMM_FROCESS receives an telephone card 
request message from the X.25 network- 
In step 808, the X25 communication module sends the telephone card 
request message to the VALIDJ?ROCESS module. The VALID_PROCESS 
module performs the protocol conversion from 3C25 to the client server protocol 
that can be used to int***^^ with the local database or data applications processor 
(DAP) to be queried. The process for protocol conversion is described with 
respect to FIG. 4. 

In step 8 1 0, the VAIIDJPROCESS sends a local database query to a local 
database. The local database is a telephone company card database. A telephone 
company card database contains customer account information used in validating 
a card issued by a telecommunications company. Information contained in a 
telephone company card database includes customer account information such as 
customer name, calling card number, and account balance. The local database 
query is a query to determine using information in the local database whether the 
card is valid and, in the case of prepaid cards, whether sufficient funds are 
available in a customer's account to process a call* The local database either 
authorizes or rejects the customer's request to bill using the card issued by the 
telephone company. 

In step 8 12, the local database sends a local database query response to the 
VALlD_PROCESS module. The local database query response indicates whether 
the customer is authorized to bill using the card issued by the telephone company. 
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However, the local database is only one type of telephone company card database. 
Customer account infonnation for cards issued by atelephone company may also 
be maintained by a data applications processor PAP). Ifthe local database query 
is database not found or data not found, the customer account information may 
be stored on the DAP for that particular type of card. If the local database query 
contains a response, the VALEDJPROCESS module next performs step 81 8. 

In step 814, if the local database query response is database not found or 
data not found, VAUDPROCESS sends a data applications processor (DAP) 
query to the DAP. Some cards, that are issued by telephone companies, such as 
calling cards, are not validated using local databases. These cards are validated 
using a database on a DAP. The DAP contains customer account infonnation 
similar to the local database such as customer name, customer account number 
and account balance. Ifthe response to the local database query is database not 
found or data not found, then the account information for the card may be 
r^intainedonlhedatabaseontheDAP. VaUdationofmecalhngcardisdoneby 

responding to the DAP query. 

In step 816, the DAP sends a DAP query response to VALID_PROCESS. 
The DAP query response indicates whether the customer is authorized to bill 
using the card issued by the telephone company. 

In step 818, VALID_PROCESS sends a telephone card reply message to 
the X.25 COMM_PROCESS module. VALID ..PROCESS converts the message 
from the client server protocol to an X25 protocol that can be understood by the 
computer system that sent the telephone card request message via the X25 
network. The process for protocol conversion is described in further detail with 
respect to FIG. 5. 

In step 820, X.25 COMMJPROCESS sends a telephone card reply 
message to the X.25 network. 

FIG. 9 illustrates message flow for validating a request message received 
on an X.25 switch virtual circuit A validation request to validate a card issued 
by a telephone company may be received on either a permanent virtual circuit or 
a switch virtual circuit from the X.25 network. Ifthe call is received on a switch 
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virtual circuit, the process is slightly different than if the call is received on a 
permanent virtual circuit 

In step 906, a parent X.25 service in module receives an telephone card 
request message from the 3C25 network. A parent service in module is a module 
that is forked out by the X.25 COMM_PROCESS module. However, unlike 
other modules that are forked out, the parent service in module is not limited to 
a particular transaction. The X25 COMMJ>ROCESS module forks out the 
parent XJ25 service in module when the system is initiated and the parent X.75 
service in module is used until the system is shut down. 

In step 908, the parent X.25 service in module forks out a child X25 
service in module. The parent X.25 service in module sends the request message 
to the child X^5 service in module for processing. 

In step 910, the child X25 service in module sends the telephone card 
request message to VALID JPROCESS. Similar to messages requesting 
validation of cards issued by telephone companies that are received on permanent 
virtual circuits, requests that are transmitted to the validation gateway 130 on 
switch virtual circuits require protocol conversion. VALID JPROCESS performs 
the conversion from X2S to the client server protocol used by the local database 
Or DAP to be queried. The process for protocol conversion is described in further 
detail with respect to FIG. 4. 

In step 912, VALID ^PROCESS sends a local database query to a local 
database. Similar to processing requests received on permanent virtual circuits, 
requests received on switch virtual circuits need to access the appropriate 
database where customer account information is stored in order to validate or 
deny the request. Customer account information such as customer name, account 
number, and account balance are stored on a local database for some cards issued 
by telephone companies. The local database query is a query to determine using 
information in the local database whether the card is valid and, in the case of 
prepaid cards, whether sufficient funds are available in a customer's account to 
process a call. The local database either authorizes or rejects the customer's 
request to bill using the card issued by the telephone company. 
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In step 914, the local database sends a local database query response to 
VALIDJPROCESS. The local database query response indicates whether the 
card issued by the telephone company is valid. Similar to processing a request 
received on a permanent virtual circuit, the customer account information may be 
stored on a DAP. If the customer account information is stored on the DAP , the 
local database query response is database not found or data not found If the local 
database query contains a response, the VALID_PROCESS module next 
performs step 920. 

In step 916, if the local database query response is database not found or 
data not found, VALIDJPROCESS sends a DAP query to the DAP. Regardless 
of whether the card request message was received on a permanent virtual circuit 
or a switched virtual circuit, if the customer account information is stored on the 
DAP, a DAP query must be sent to the DAP for authorization. 

In step 918, the DAP send a DAP query response to VALIDJPROCESS. 
The DAP query response indicates whether the customer is authorized to bill 
using the card issued by the telephone company. 

In step 920, VALIDJPROCESS sends a telephone card reply message to 
the child X25 service in module. Similar to processing of other messages, 
VALIDJPROCESS provides protocol conversion. In this step, the protocol 
conversion is from the client server protocol to X.25 protocol. The process for 
protocol conversion is described in further detail with respect to FIG. 5. 

In step 922, the child X.25 service in module sends a telephone card reply 
message to the X.25 network. The telephone card reply message is sent on the 
switch virtual circuit that was used for sending the request Use of the switch 
virtual circuit ends when the transaction for a particular request is complete. 

In step 924, the parent X.25 service in module terminates the child X.25 
service in module. The child X.25 service in module is used for processing only 
one particular transaction. When that transaction is completed, the parent X^5 
service in module terminates the child X.25 service in module. 

The system and method of the present invention may be used in 
processing a validation request to pay for telecommunication services other than 
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prepaidseMceswimacreditcard. Forex-pl^n^couldpayendofthe 
month bi.U using credit cards by diaUng m to . — or — - H"*- 

fi^U „ . debit account, *e validation gateway 130 — — *■ 

from to teiec.tnn.ria.ions r^k and send the reo^ «» a finanaa! 

pr^or 132,i. m X25 network P^ssi.gofter.qu^tob. sen. «oa 

filial processor 132 is the same regards of the services being paid for rf 
validation requests are received from the AIN 124. 

•n* system and method of the present invention is also not limned to 

pmvidingunmterface for transact 

ta^ processors 132. The system and method of the present invention may 
be used whenever comnumtamon is needed between a client server network and 
a network using X.25 pro«»col. The validation gateway can perform message 
tracer and protocol conversion between any computer systems requtang 
message transfer and client server to X25 protocol conversion capab.Ut.«. 

tfthepresenttarentionisusedtotra^ 
other mar. credit card validation, the transaction data included in the validation 
request and response messages and the card request and reply messages would be 
transacfiondataneededformepamc^tnuBaction. For example, if me present 
tovermonisusedmr^ormpromcolc^ersionfer messages sent from a remote 
au«om«ed unit on a client server netwo* • a database on an X2S network to 
make a reservation on a particular airline flight if a seat is available, the 
taction data in one embodiment of the validation request and response 
messages and the card request and reply messages would include a particular 
airline, date, and flight number. 

Emb«Br«entsofthc validation gateway can irterrto with networks usmg 
mry type of client server protocol such as UDP/IP. In addition, the validation 
gateway is not limited to interfacing with Artworks using X.25 protocol. The 
system and method of the present invention can provide message transfer and 
protocol conversion for any packet switching network protocol. 
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in addition, the system and method of the present invention may be 
indented using various formats fox the validation request message the 
telephone card request message, the telephone card reply message and the 
validationreplymessage. The vahciation request message need not be m request 
information format Any format containing information needed to process a 
credit card request canbeu.ed. Similarly, the telephone card request message 

andtelephonecardreprymess^ 
theteleptonecardr^^ 

information necessary to obtain reply authorization and can be understood by a 
processor accessed via a packet switching network. In addition, the validation 
reply message does not need to be in request information format Again, if the 
information needed to process a reply is included in the message, the format of 
the message can be used with the present invention. 

Another embodiment of the present invention does not require that a non- 
billableBDRis written. Because settlement occurs real-time with authorization, 
a BDR is not needed to process the customer billing. Therefore, an embodunent 
of the present invention does not include a non-billable BDR being written by 
either a manual operator console or validation gateway 1 30. 

In an additional embodiment of the present invention, authorization 
requests are processed automatically by automated operator consoles rather than 
the SSCP 138. Automated operator consoles, also referred to as automated 
response units, are used to process many automated telecommunications services. 
The system and method of the present invention may be used with any caller 
interaction processor that can obtain information needed from the customer to 
process the call. 

The system and method of me present invention may also be used with an 
X.25 COMMPROCESS that does not fork out a child process or service in 
process. The X25 COMM.PROCESS is a single point of interface between the 
VALID.PROCESS and the X.25 network. Any module that can perform the 
interface functions between VALID.PROCESS and the X.25 network or other 
packet switching network may be used. 
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the particular authorization transaction. 
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calls. 
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Tte SNAP selects a manual operator console and ensures 
£ ESSS - distributed among the logically 
defined groups of manual operator consoles. 
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„,t£itoustag TOP/IP protocol. 
UDP/IP and X- 25 - 

Validation Process Module tm .pp 

interaction processor. ^ addition, VALlu rK 
S validation response messages wngcrt reply 
™™cs received from a financial processor. 
vSd P^ESS provides the protocol conversion 
between UDP/IP and X.25. 



X.2S COMM_ 
PROCESS: 



X.25 C-m&JZ-JgZ, coraputtI 
program process forks out a child 
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1. 

of: 



What Is Claimed Is: 

AB1<1-fc «*.«---*«— — ■ 

gateway to said caller interaction processor. 

2 Tne method of claim 1, further comprising: 

« vmtingbysaidvalidationgatewayabininBdatarcc.rd^ 

a network information distribution service database server. 



account; 



3 The method of ctan 1, "tea* step (a) comprises 

said customer credit card account; 

collecting transaction data by an operator, 
entermgsaidtramact^ 

message to bill to said customer credit card account; and 
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, vA«« m rateway a validation request message 
receiving by said validation gateway a 

containing transaction data; _ a operator 

caller interaction processor compnses man 



wherein said caller 
console. 



to said customer credit card account; 

• ^*,fcv«iid caller interaction processor, 
mllectine transaction data by saia cauw u«« 

^chtag by arid validation a vah,lanon ^ 

wherein said caller W""*"" P 1 "** 501 ""^ 
eonto,! point oranautomated response unit 

5 Tnem^ofctol.^ereinstepWcomprises: 

populating by said caller interaction processor one or more ^^j^ 
^JL. in -d va«d«ion ~* — - - ~ ~ 

^"Iding by s*d caler in^on processor said validation reojtes, 

message to said validation gateway. 

6 Therr^odofclaiml.whereinstepWcomprises: 

sravi ce provider and a corner credit card account idennner obtanted from 
customer r a customer credit card; 
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and 



popular b, s*d cdter i^cSon processor or* or mo* v^on 

..j • ^ ^occmre with additional transaction data; 

request fields in said validation request message witn aaoro 

sending by said caller interaction processor said validation request 

message to said validation gateway; 

therein said validation request message is in a request information 

format. 

7 The method of claim 1, wherein step (b) comprises: 

receiving by said validation gateway from said caller interaction processor 

said validation request message; 

retrieving transaction data from said validation request message; 
storing said transaction data in a local message pending list; and 
bunding a card request message using said transaction data received m 

said validation request message. 

8 The method of claim, 1 wherein step (b) comprises: 

receiving by a client receive module of said validation computer program 
on said validation gateway from said caller interaction processor said validation 

request message; 

sendmgs^dvaUdanon^ 
to a validation module of said one or more validation computer programs on said 

validation gateway; 

retrieving transaction data from said validation request message by said 

validation module; 

storing by said validation module said transaction data in a local message 

pending list; 
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b»aain g b, said «lMm™* ■« — *" — 

II!1 ^oi.dataiii»id«lidati<.ni« P «ame SS aeei>nd 

«», s»d c*d a—* -* "** *° 

gateway. 

9 The method of claim 1. wherein step (e) comprises: 

sending said card request message from a communications module of a 
validation computer program on said validation gateway to said finanaal 
processor. 

10 The method of claim i, wherein step (d) comprises: 

living by a conjunctions module of a validation computer program 
on said validation gateway a card reply message from said financial processor. 

11 The method of claim 1. wherein step (e) comprises: 

receiving by said validation gateway from said financial processor said 

card reply message; 

retrieving reply data from said card reply message; 

mapping said reply data to an response code; 

retrieving transaction data from a local message pending list; and 

building a validation response message using said transaction data from 
said local message pending list and said response code. 

12. The method of claim 1, wherein step (e) comprises: 

receiving bya communications module of a validation computer program 

on said validation gateway from said financial processor said card reply message; 
sending said card reply message from said communications module to a 

validation module of said validation computer program on said validation 

gateway; 
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a*horiz*ion da. from said «rd reply message by said 

validatioa module; 

Hoping aid auftorizarion data from said cod reply message; 

wrie^tnmsaction data Son a local message pending list; 

M^bys^vaBdadonmoduleay.Oidaaon response messaged 
^t^^n^atasrid local me^er*nding lis. and said response code; 

a cUent send module of said validation computer program on said vaUdanon 



gateway. 



13 TTjemethodofclaim^whereinstep^comprises: 

sending by a validation module of a validation computer program on said 
vaUdation gateway a billing data record write request to a nonlocking 

application modules; 

sending by said non-blocking application module said billing data record 

•write request to a client process module; 

sending by said client process module a billing data record write request 

to a billing data record service; 

sending by said billing data record service a billing data record write 

response to a demultiplex process module; 

sending by said demultiplex process module a billing data record write 

response to said client process; 

sending by said client process module a billing data record write response 

to said non-blocking application module; and 

sending by said non-blocking application module a billing data record 
write response to said validation module. 

14. A method of converting a message from a client server protocol to a 
packet switching network protocol, comprising the steps of: 
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W ^by.cUent.ceiv.^uleofavaU.Woncomp^ 
^ on said vaiidanon *om a die* of . client — — * • 

validation request message; 

(b) sending said vaUdation request message from said chent receive 
mo dule of said validation computer program to a validation module of said 
validation computer program on said validation gateway; 

(e) retrievmgtrar^on^ 

by said validation module; 

(d) storing by said vaUdation module said transaction data » a local 

message pending list, 

(.) building by said validation module a packet ****** network 
cobble leanest message fi- said transaction data in said iocal message 

pending list; 

(f) sending said packet switching network compare request 
message from said validation module to a communications module of said 

(g) sending said packet switching network compatible request 
mcssagc from said communications module of said validation computer 
programs on saidvaUdation gateway to apacket switching network. 

15 Tne method of claim 14, wherein step (g) comprises: 

sending said packet switching network compatible request message from 
said commum^onsmodulecm^ 

network via one or more permanent virtual circuits between said validaUon 
gateway and said packet switching network. 

16 The method of claim 14, further comprising: 

forkmgoutanX.2SserViceoutmodulebysaid communications module; 

sending said packet switching network compatible request message from 
said communicauons module to said X.25 service out module; and 
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,., a »^Ktc.«i<lp.*«««i«*in8 I,<!,wolkvia<>ne ° imMt 

SI — — — ' - - - 

switching network. 

protocol to a client server protocol, comprising the steps of: 

(a) ^ 
program a reply message from a packet switching network; 

(I,) sending by said communications module said reply message to a 
validation module of said validation computer program; 

(c) .etrieving transaction data from a local message pending list; 

(d) building by said validation module a validation response message 

including said response code; and 

(e) sending said validation response message from wd vahdauon 
module to a client send module of said validation computer program. 

18 The method of claim 17, wherein step (a) comprises: 

receiving said reply message by said communications modulo of said 
validanoncomput^ 
permanent virtual circuits. 

19 The method of claim 17, wherein step (d) comprises: 

retried transaction data and reply data by said validation module from 

said reply message; 

selecting by said validation module a response code that corresponds to 

said reply data received in said reply message; and 

building by said validation module a validation response message 

including said response code. 
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"^iLg * said X., 5 se^ce .« — said - - 

gateway. 

to be oerfbnned before step (a): 

living * . X* -vice ou, module of said — con*** 

p^oa.vaHdaions *"« 
n ^vi»oneormon ! sv4tchedviin^cucm« a nd 

sodtog by add JUS service out module said reply message .o sa,d 
gateway. 

a client server protocol from a computer program using a packet switching 
network protocol, comprising the steps of: 

00 receiving by a communications module of a vahdauon computer 
programa request message from a packet switching network; 

(b) sending by said communications module said request message 
toavalio^onmoduleofsaidvaUdationcomputerprogram; 

(e) sexaotagbysaidvanda^ 
database; 

(d) receiving by said validation module a local database query 
response from said local database; 
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/a\ fh«t said local database query 

(e) if it is determined in step (d) that sa,d 10 

w j *«,«/4ino bv said validation 

r^nse is database not found or data not found, sendmg by sai 
response is data Q a ^ applications processor, 

module a data applications processor query 

(f) if in step (e) said data appHcaUons processor query^ t 

from said data applications processor, 

fc) sending by said vaUdation module a reply message to sai 

communications module; and , messaceto 

(h) sendingbysaid communications module S a,d reply message to 

said packet switching network. 

. ^ m a computer program using a packet switcmng 
a client server protocol trom a compuier v & 

network protocol, comprising the ste^of : 

M receiving by a parent X2S service xn mo 

„«t m( * 5 aae from a packet switching network; 
computer program a request message Horn P eW i d y 2 5 

j y 75 service in module a child A.-" 

(b) forking out by said parent sexvi^ 

service in module; 

(c) sending by said child Xi5 service in module sa>d «ques. 
^.o.vaUdationm.dul.ofsaidvdiia.ioucompu.crpro^ 

(d) ^*M<**-~"'*»**~~ vaVOm ** 

^ r^vins by ^ valine module a local daabue query 
^tensaidlocalda^ 

(ft if it is determmed m step (e) mat saia wi> 
KSpM se iS database not four* or da, not found, sendin B b, said val^on 

w if in skp (0 »id data applications processor query » sent, 
ten aid data applications processor, 
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w ^^^^^^^ 

0 terminating said child X-» service m 
service in module. 

w^rc-^soraccessedviaapacketswrtching 
•>a A method for responding by a processor aw 

convert said valid**. re*** — * *» * ** ~~ 

^..oapad— , 0 ^ procrasorv U .aid 
sending a converted request message to saio pru 

packet switching network; 

receiving areply message from said processor, 

protocol to a client server protocol; and 

sending said validation response message to said client 

client server network. 

25 A computer system network, comprising; 

. service «. P°in« for storing debi, cuflomer account 

.ndv^in^ne^^coup.edu.saidservice 

oneormoreope^rne^rkcentercomputersys-emscoupicd 

, OS aidadv««xair.telUgentnet«orlc$ateway; 

a^Wong-eway^ledtooneofsaidoneormoreope^ 

„ eW o* center computer systems and coupied • » processor via a paefcet 
switching network; and 
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one or more operator consoles coupled to one or more of said 
operator network computer systems. 

26 A computer system network comprising: 

a service data point for storing debit customer account 

infbnnalion; 

«n advanced intelligent network gateway coupled to said service 

data point; 

one or more operator network center computer systems coupled 

to said advanced intelligent network gateway; 

a validation gateway coupled to one of said one or more operator 
network center computer systems and coupled to a processor via a packet 

switching network; and 

a service switching control point coupled to said service data 

point 
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inventive concept under PCT Rule 13.1. In order for all inventions to be searched, the appropriate additional search 
fees must be paid. 

Group I, claira(8)l-13, drawn to a method for credit card billing. 

Group II, claim(s) 14-24, drawn to a method for protocol conversion. 

Group III, claim(s) 25 and 26, drawn to a client/server computer system network. 

The inventions listed as Groups I-III do not relate to a single inventive concept under PCT Rule 13. 1 because, under 
PCT Rule 13.2, they lack the same or corresponding special technical features for the following reasons: Groups Mil 
are related as combination and subcombinations. Inventions in this relationship are distinct if it can be shown that (1) 
the combination as claimed docs not require the particulars of the subcombinations as claimed for patentability, and (2) 
that each subcombination has utility by itself or in other combinations (MPEP 806.05(c)). In this instant case, the 
combination as claimed does not require the particulars of the subcombinations as claimed for patentability, and that 
each subcombination has utility by itself such as credit card billing device and protocol converting device. 
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